The Evolution from Software Components to Domain Analysis

BEGIN l o w l e v e l t r a n s f o r m a t i o n s c a n r e q u i r e a l o t o f A I p l a n n i n g SUM:=1; TOP:=2*LN(X); TERM:=1; [Fickas85]. FOR I:=1 TO 20 DO BEGIN Now consider this same matrix multiply example in a language TERM:=(TOP/I)*TERM; SUM:=SUM+TERM; l i k e A P L t h a t e m b r a c e s t h e c o n c e p t o f m a t r i c e s a n d m a t r i x END; operations. This new language is at a higher level of abstraction RETURN SUM; t han the usual algorithmi c p r o g r a m m i n g l a n g u a g e . G i v e n t h a t END; 1 i s t h e i d e n t i t y m a t r i x i n t h i s n e w l a n g u a g e t h e i d e n t i t y m a t matrix multiply becomes the simple transformation. Figure 2: Implementation of X**2 using Taylor Expansion LHS: C :=1 *B <=> RHS: C :=B mat mat mat mat mat T h e “ b i n a r y s h i f t m e t h o d ” e x p a n s i o n m a y b e r e d u c e d t o a EC: structures of C and B are equal s i m p l e m u l t i p l y b y c h a i n i n g t o g e t h e r m a n y l o w l e v e l a l g o r i t h m i c l a n g u a g e s o u r c e t o s o u r c e t r a n s f o r m a t i o n s s i m i l a r Notice that this is similar to the transformation for multiplying to the process of transforming matrix multiply by the identity integers or reals by 1 in algorithmic languages. From this simple m a t r i x . T h e “ T y l o r e x p a n s i o n m e t h o d ” e x p a n s i o n c a n n o t b e a example we can see that a lot of hard work can be avoided by r e d u c e d t o a s i m p l e m u l t i p l y b y g e n e r a l l o w l e v e l creating levels of abstraction above algorithmic languages that t r a n s f o r m a t i o n s b e c a u s e i t i s a n a p p r o x i m a t i o n o f directly define the concepts of interest. exponentiation. It suffices as an implementation because of its context (in this case that 20 terms of accuracy is acceptable) but T h e e x a m p l e a b o v e d o e s n o t a d v o c a t e d o i n g a w a y w i t h t h e it is not equivalent. Other investigators in this area ran into the l o w l e v e l a l g o r i t h m i c t r a n s f o r m a t i o n s . T h e y s e r v e a u s e f u l same problem. purpose in the optimization of general programs under arbitrary c o n d i t i o n s . C o n s i d e r t h e c o m p l e x o p t i m i z a t i o n p e r f o r m e d b y “ W a r e a b l e t o m a k e f u l l u s e o f t h e a l g e b r a i c l a w s e t h e t r a n s f o r m a t i o n s u n d e r t h e a s s e r t i o n s t h a t A i s a n u p p e r appropriate to this higher level. F r example, once calls o triangular matrix and B is a lower-triangular matrix. t o s e t o p e r a t i o n s h a v e b e e n r e p l a c e d b y t h e i r l i s t p r o c e s s i n g b o d i es many possibilities f o r r e a r r a n g e m e n t A[row,col] -> (IF row (IF row>col THEN B[row,col] ELSE 0) These examples show that very simple mechanisms (source-toI n s o m e c a s e s i f a t r a n s f o r m a t i o n i s n o t p e r f o r m e d a t a h i g h source transformations) applied at a higher level of abstraction enough level of abstraction then the effect of the transformation can exceed in power v e r y c o m p l e x m e c h a n i s m s ( A I p l a n n i n g m a y n e v e r b e a c h i e v e d . C o n s i d e r t h e c a s e o f a n a l g o r i t h m i c a n d d a t a fl o w a n a l y s i s ) a p p l i e d a t l o w e r l e v e l s o f a b s t r a c t i o n . l a n g u a g e a n d a n e x p o n e n t i a t i o n op e r a t o r ( * * ) . I f t h e p h r a s e Some optimizations are no longer possible as we go to lower X * * 2 w e r e e n c o u n t e r e d i n a p r o g r a m w e c o u l d e m p l o y t h e levels of abstraction. Level of abstraction knowledge about the simple source-to-source transformation problem domain is more powerful than general mechanisms. LHS: X**2 <=> RHS: X*X T h e r e a d e r m i g h t w e l l a s k “ W h o w o u l d w r i t e p r o g r a m s EC: X is side-effect free c o n t a i n i n g s u c h s t a t e m e n t s a s X * * 2 ? ” S y s t e m s t h a t c o m b i n e very general software components create such statements all the t o c o n v e r t i t t o m u l t i p l i c a t i o n ; o r w e c o u l d m a c r o e x p a n d a t i m e . T h e y r e fl e c t g e n e r a l i t y t h a t i s n o t b e i n g u s e d i n a general implementation of the exponentiation operator and then particular case. The role of source-to-source transformations is t r y t o s i m p l i f y . T h e “ b i n a r y s h i f t m e t h o d ” i s a g e n e r a l t o s m o o t h o u t t h i s g e n e r a l i t y u s i n g a s i m p l e m e c h a n i s m o n expansion of the exponentiation operator when the power is a concepts at a high level of abstraction. Any work that seriously positive integer. The macro expansion of X**2 using the binary u s e s l a y e r s o f k n o w l e d g e a b s t r a c t i o n w i l l e m p l o y s i m p l e shift method is shown in figure 1. source-to-source transformations for optimization. 4 The Evolution from Software Components to Domain Analysis Program Transformations I i n v e s t i g a t e d a s i m p l e s c h e m e o f M a r k o v p r o c e s s e s t h a t The arc h i t e c t u r e i s s e p a r a t e f r o m function. The basic tenet of provides a procedural capability with proof of termination for g o o d d e s i g n i s t h a t a s y s t e m a r c h i t e c t u r e s h o u l d f o l l o w t h e source to source transformations [Neighbors80]. This scheme is d e c o m p o s i t i o n o f t h e s y s t e m f u n c t i o n . T h i s t e c h n i q u e b r e a k s u s e f u l f o r t r a n s f o r m a t i o n s t h a t m u s t p r o p a g a t e o r u s e g l o b a l down when we stop modeling the objects and operations of the information. p r o b l e m d o m a i n a n d s t a r t u s i n g k n o w n C o m p u t e r S c i e n c e a b s t r a c t i o n s t o m o d e l t h e p r o b l e m . T h e c l o s e n e s s o f t h e t o p Lessons from Program Transformation Research: l e v e l s o f a r c h i t e c t u r e a n d f u n c t i o n s o m e t i m e s l e a d s t o t h e i r confusion. 1. T h e r e a r e f e w , i f a n y , e q u i v a l e n c e p r e s e r v i n g I n S o f t w a r e E n g i n e e r i n g t h e r e a r e t w o b a s i c a p p r o a c h e s t o transformations. This is not a problem as exemplified developing system architecture: stepwise refinement [Wirth71, b y o p t i m i z i n g c o m p i l e r s . C o r r e c t n e s s p r e s e r v i n g D i j k s t r a 6 9 ] a n d l a y e r s o f v i r tual machines [Dijkstra68]. S t r i c t transformations in a given context are the issue. stepwise refinement stresses the decomposition of a system: 2. Using concepts at the “right” level of abstraction is a n e x t r e m e l y powerful optimizati o n t e c h n i q u e . T h i s “ A g u i d e l i n e i n t h e p r o c e s s o f s t e p w i s e r e fi n e m e n t r e p r e s e n t s a t r a d e o f f b e t w e e n p l a n n i n g a n d should be the principle to decompose decisions as much knowledge. a s p o s s i b l e , t o u n t a n g l e a s p e c t s w h i c h a r e o n l y 3. The rules of exchange in a domain must be absolute s e e m ingly interdepende n t , a n d t o d e f e r t h o s e d e c i s i o n s w i t h r e s p e c t t o t h e s e m a n t i c s o f t h e d o m a i n . T h i s w h i c h c o n c e r n d e t a i l s o f r e p r e s e n t a t i o n a s l o n g a s m e a n s t h e r u l e s a p p l y i n d e p e n d e n t o f a n y possible.” [Wirth71] i m p l e m e n t a t i o n s c h o s e n f o r t h e d o m a i n . T h e granularity of the semantics of a domain only applies Strict stepwise refinement results in architectures that are treeto statements in the domain – not implementations. like as functions are subdivided into separate subfunctions. The module reference structure of a system produced using stepwise refinement might appear as shown in figure 3. System Architecture Software Engineering system architecture theories gave me the t o o l s t o c o p e w i t h c o m p l e x i t y . I f s o f t w a r e c o m p o n e n t s w e r e e v e r t o b e a s u c c e s s , c l e a r l y s o m e t h i n g b e y o n d i n c l u d i n g millions of components into a flat catalog must be the goal. The early Software Engineering discussions on levels of abstraction provided very strong ideas. “ W u n d e r s t a n d c o m p l e x t h i n g s b y s y s t e m a t i c a l l y e Figure 3: Stepwise Refinement Architecture b r e a k i n g t h e m i n t o s u c c e s s i v e l y s i m p l e r p a r t s a n d understanding how these parts fit together locally. Thus, Inherent in the stepwise refinement model is the assumption of we have different levels of u n d e r s t a n d i n g , and each of fl e x i b i l i t y a t t h e b o t t o m o f t h e a r c h i t e c t u r e . T h e p r i m a r y these levels corresponds to an abstraction of the detail of constraining factors come from higher levels of abstraction. the level it is composed from. F r example, at one level o o f a b s t r a c t i o n , w e d e a l w i t h a n i n t e g e r w i t h o u t C r e a t i n g a r c h i t e c t u r e s f r o m l a y e r s o f v i r t u a l m a c h i n e s w a s considering whether it is represented in binary notation described by Dijkstra. o r t w o ’ s c o m p l e m e n t , e t c . , w h i l e a t d e e p e r l e v e l s t h i s representation may be important. At more abstract levels the precise value of the integer is not important except as “ P h r a s i n g t h e s t r u c t u r e o f o u r t o t a l t a s k [ b u i l d a it relates to other data.” [Knuth74] multiprogramming operating system] as the design of an ordered sequence of machines provided us with a useful f r a m e w o r k i n m a r k i n g t h e s u c c e s s i v e s t a g e s o f d e s i g n The problems with building large software systems in the late a n d p r o d u c t i o n o f t h e s y s t e m . B u t a f r a m e w o r k i s n o t 1 9 6 0 s p r o m p t e d t h e s t u d y o f h o w systems are produced . T h e very useful unless one has at least a guiding principle as discussion at the 1968 and 1969 NA O conferences focuses on T to how to fill it in. Given a hardware machine A[0] and p r o c e s s a n d a b s t r a c t i o n . S u d d e n l y t h e r e w a s a l o t o f t h o u g h t the broad characteristics of the final machine A[n] (the a b o u t h o w l a r g e s y s t e m s a r e p a r t i t i o n e d i n t o p a r t s a n d h o w value of ‘n’ as yet being decided) the decisions we had t h e s e p a r t s a r e i n t e r f a c e d . L a t e r r e s e a r c h p r o g r a m m i n g to take fell into two different classes: languages such as Clu and Alphard incorporated the abstraction i d e a a n d p r o v i d e d t h e a b i l i t y t o c r e a t e c o m p o n e n t i n t e r f a c e s stronger than “sockets” and “busses”. The result of partitioning 1. we had to dissect the total task of the system a s y s t e m i n t o p a r t s b e c a m e k n o w n a s t h e a r c h i t e c t u r e o f a into a number of subtasks s y s t e m . T o l s t h a t p r o d u c e c o d e u s i n g s o f t w a r e c o m p o n e n t s o 2. we had to decide how the software taking care create system architectures either implicitly or explicitly. of those various subtasks should be layered. It i s o n l y t h e n t h a t t h e i n t e r m e d i a t e m a c h i n e s System architecture is how a system is structured to perform its ( a n d t h e o r d i n a l n u m b e r ‘ n ’ o f t h e fi n a l function. F r a specific system there is only one system function o machine) are defined. but there are many architectures that can provide that function.